home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0027-Re TDocument (again-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  3.8 KB  |  70 lines  |  [TEXT/GEOL]
  1. Item    1260066                         8-June-89        11:41
  2.  
  3. From:   ALGER                           Alger, Jeff
  4.  
  5. To:     MACAPP.TECH$                    MACAPP Tech
  6.  
  7. Sub:    Re: TDocument (again)
  8.  
  9. Carl et Al..
  10.  
  11. Some additional thoughts on the TDocument issue.  I agree totally with the need
  12. for some visual object for the user to manipulate; checking options in a menu
  13. is too ... well, it's just not a Mac approach.  Where I part ways is with the
  14. concept of a TDocument as the be all and end all of the interface and the
  15. internals, perhaps even the name "document" itself.  To me, a "document" should
  16. be something I can print.  That applies to a word processing document or a
  17. drawing.  It does not apply to more complicated aggregations of data such as
  18. databases.  There is no visual, hardcopy analogy to a database; only to
  19. portions of that database as retrieved by a query and arranged by one or more
  20. programs.
  21.  
  22. The other problem I have with the concept of a TDocument as it exists today is
  23. that it encourages a close tie between the organization of data as perceived by
  24. the user (i.e., windows) with the underlying sources and sinks of data
  25. (DoRead/DoWrite methods).  Several of the links suggest refinements to
  26. TDocument to allow, say, one TDocument to "control" several TFile or whatever
  27. instances.  Yet, this still clings to a hierarchy in which the user's perceived
  28. organization is a partition of the underlying data, a concept which is in many
  29. cases simply not valid.
  30.  
  31. Consider a relational DBMS which allows relations (files) to be virtual; i.e.,
  32. logically defined and derived at run time rather than physically stored.  One
  33. such logical view (view in DBMS parlance, not MacApp) of the data may combine a
  34. local database with one or more remote ones, or several local ones.  The only
  35. thing one can describe as "the" document is the entire interface to the
  36. database(s), which to a user is indistinguishable from the application itself.
  37. I claim that this is not at all useful in presenting the data to the user, who
  38. should be as oblivious as possible to the underlying processing and structures.
  39. Indeed, the application program itself may be unaware of how these views are
  40. constructed, particularly with gateway products like CL/1!
  41.  
  42. The most natural "document" for the user may be a report or a data entry
  43. window, both of which can be printed, while the most natural "document" for the
  44. program, if there is one, is the query or the relation.  Neither necessarily
  45. corresponds to the underlying structure of the database(s).  To insist on
  46. mapping these three into some sort of TDocument-controlled hierarchy is
  47. difficult and without merit.  It also flies in the face of the experience of
  48. the database community, which is that databases should be designed and
  49. maintained independently of the applications which use them.  "Documents" in
  50. the Mac interface are creatures of the application; the data may have an
  51. independent life and may, in fact, appear differently to different users and
  52. applications, both in structure and content.
  53.  
  54. In short, let TDocument be a creature of the user interface and develop richer
  55. - and more appropriate - classes to deal with internal organization.  I have
  56. used databases for my soapbox throughout my links, but I feel that the
  57. principle is valid in non-database environments as well.  Any time the physical
  58. organization of data does not correspond to the printed - and, by implication,
  59. visual - organization, or when multiple applications share the same data, the
  60. current TDocument usage is trouble.  This happens often enough that it should
  61. be split in two.
  62.  
  63. As to specific suggestions for what that underlying structure should be, I will
  64. need a couple of days to organize my thoughts and will then send a follow-up
  65. link.  In the meantime, what does everyone else think?
  66.  
  67. Jeff Alger
  68. Peat Marwick Main & Co.
  69.  
  70.